A processor or controller can have many available methods to boot an application. Some applications using these products may desire to load code from an external memory via one of many communications peripherals into on-chip random access memory (RAM) or even run the program directly from that external memory; others may boot from internal non-volatile memory (NVM); and others may connect to a host for the purpose of programming the internal NVM. In a general purpose processor/controller, which can be programmed for any number of different tasks, it is desirable for the manufacturer to provide a mechanism to allow customers to choose which boot method they prefer. One known method is to provide log2 (n) pins to allow a selection between n options, e.g., one pin allows two choices, two pins allow four choices, etc. However, this method expends pins, which are a valuable commodity on a processor/controller. Various solutions to the expenditure of pins have been suggested, but none offer both the ability to provide low- or no-pin use while also securing the boot process from unauthorized users.
One way to reduce the number of pins dedicated to boot selection is to have the on-board Central Processing Unit (CPU) listen to all possible communication peripheral ports for a golden signature that signals the selection of the specific port being used. Once such a signature is seen, the boot process is continued via the respective peripheral. However, this method does not allow a customer to disable booting through one or more specific peripherals. All communication peripherals are always enabled. This may not be desirable from a security standpoint because these paths are available for an unauthorized user to download a “spoof” application.
Another way to reduce the number of boot pins is to allow users to program their desired boot method into on-chip NVM. Previous implementations used in the past have had one or more of the following limitations:                The user cannot eliminate all of the boot pins, thereby reducing the available usable pins for the customer;        The user cannot eliminate undesired boot options to secure the boot process; and        The user cannot choose between two or more non-default boot options to allow alternate boot methods (e.g., default boot to Flash and a firmware upgrade option via Serial Peripheral Interface (SPI)).        